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Direct transition to CELLJDCH 



FIELD OF THE INVENTION 

The present invention relates to a method and arrangement to 
5 achieve an improved Cell Update message format in a UMTS 
Radio Access Network (UTRAN) . 



BACKGROUND OF THE INVENTION 

In UTRAN a user equipment {UE) can be in one of several RRC 
10 states depending on the user activity- These states consist 
of Idle Mode, URA^PCH, CELL_PCH, CELL___FACH and CELL_DCH, 
listed in order of increasing user activity. 

The CELL__DCH state provides the best user performance in 
terms of data rate and delay, but also consumes the most 

15 resources, e.g. in terms of power and codes. Thus it may be 
necessary to move users to lower states when the data 
transmission stops. A typical case for many applications is 
that data transmission occurs so seldom that the UE is in 
CELL_PCH or URA__PCH state when a data burst transmission 

20 starts. This implies that the delay to move from 
CELL_PCH/URA__.PCH to CELL_DCH needs to be minimized, in order 
to have a good user performance. If the application 
transmits small data objects the time to change state will 
have a more significant impact on the user performance than 

25 the data rate on DCH. A Push-to-Talk service is one example, 
where rather small objects are transmitted rather 
infrequently. This service could start with a burst from the 
network side if the terminal in CELL PCH/URA PCH is the 
receiver of the talk burst. In this the delay for 
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transmitting a data object (including transition to 
CELL_DCH) is to a large extent determined by the time to 
move from CELL/URA_PCH to CELL_DCH. 

When a UE in CELL/URA_PCH needs to transmit uplink data, the 
5 typical signalling sequence is shown in figure 1. In step 1, 
the UE sends a Cell Update message to indicate that it has 
uplink data available to transmit. In step 2, UTRAN responds 
with transmitting a Cell Update Confirm message which 
acknowledges the Cell Update Message and orders the UE to 
10 enter CELL_FACH state, where data transmission is possible, 
in step 3, The UE transmits a UTRAN Mobility Information 
Confirm message to acknowledge the Cell Update Confirm 
message. It is now possible for the UE to transmit data on 
RACH, i.e. it is in CELLJFACH state. If the available amount 
15 of data, which is denoted the Traffic Volume in 3 GPP 
specifications, is above a configured threshold the UE 
transmits a Measurement Report to inform UTRAN about the 
available amount of data (step 4) . When UTRAN receives the 
Measurement Report it can decide to move the UE to CELL_DCH 
2 0 since the RACH has very limited performance. UTRAN therefore 
sends a Radio Bearer Reconfiguration message in step 5 to 
move the UE to CEIiL_DCH. The UE responds with a Radio Bearer 
Reconfiguration Confirm message in step 6, which 
acknowledges the received message. Now the UE has entered 
25 CELL_DCH and can transmit data on the DCH. 

Correspondingly, figure 2 depicts the typical signalling 
sequence when a UE in CELL/URA_PCH needs to receive downlink 
data. The UE receives in step 1 a paging message. The UE 
shall answer such a paging message. In step 2, the UE 
30 answers the paging message by sending a Cell Update message 
to indicate that it has received the paging mesage. In step 
3, UTRAN responds with transmitting a Cell Update Confirm 
message which acknowledges the Cell Update Message and order 
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the UE to enter CELL_FACH state, where data transmission is 
possible. In step 4, The UE transmits a UTRAN Mobility 
Information Confirm message to acknowledge the Cell Update 
Confirm message. It is now possible for the UE to receive 
data on FACH (i.e. it is in CELL.FACH state). If the 
available amount of data buffered for this UE in the MIC 
(denoted Traffic Volume in 3 GPP specifications) is high 
enough as evaluated by UTRAN, it can decide to move the UE 
to CELL_DCH since the FACH has very limited performance. 
UTRAN therefore sends a Radio Bearer Reconfiguration message 
in step 5 to move the UE to CELL_DCH. The UE responds with a 
Radio Bearer Reconfiguration Complete message in step 6, 
which acknowledges the received message. Now the UE has 
entered CELL_DCH and can receive data on the DCH. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 shows a normal signalling sequence for moving a UE 
from CELL/URA_PCH to CELL_DCH in case of a UE initiated 
transmission . 

Figure 2 shows a normal signalling sequence for moving a UE 
from CELL/URA_PCH to CELL_DCH in case of a UTRAN initiated 
transmission . 



Figure 3 shows an alternative signalling sequence for 
moving a UE from CELL/URA_PCH to CELL_DCH in case of a UE 
25 initiated transmission. 

Figure 4 shows an alternative signalling sequence for 
moving a UE from CELL/URA_PCH to CELL_DCH in case of a 
UTRAN initiated transmission. 
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Figure 5 shows an enhanced signalling sequence for moving a 

UE from CELL/URA_PCH to CELL.DCH in case of a UTRAN 
initiated transmission. 

Figure 6 shows an enhanced signalling sequence for moving a 

UE from CELL/URA_PCH to CEL,L_DCH in case of a UTRAN 

initiated transmission with pre-conf iguration of the 
physical channel configuration to be used on DCH. 



10 DESCRIPTION OF THE INVENTION 

Another alternative for moving a UE from CELL/URA_PCH to 
CELL.DCH is depicted by help of figure 3. According to this 
alternative it would also be possible with the current 3GPP 
specifications to order the UE to CELL_DCH directly in the 
Cell Update Confirm message. This would result in a 
signalling sequence as shown in figure 3. In this 
alternative, the UTRAN orders the UE to CELL_DCH already in 
the Cell Update Confirm Message in step 2. The UE responds 
with a Radio Bearer Reconfiguration Complete message in step 
3 and can then start to transmit data on DCH. 
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Correspondingly, figure 4 shows an alternative signalling 
sequence for moving a UE from CELL/URA_PCH to CELL.DCH in 
case of a UTRAN initiated transmission. Here, the UTRAN 
orders the UE to CELL_DCH already in the Cell Update Confirm 
Message in step 3. The UE responds with a Radio Bearer 
Reconfiguration Complete message in step 4 and can then 
start to receive data on DCH. 

The alternative signalling sequence for UE initiated 
transmission described above by help of figure 3 is much 
faster than the normal sequence. In practice the time to 
move from CELL/URA_PCH to CELLJDCH can be more than halved. 
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However, this alternative sequence also implies the problem 
that the UTRAN has no information about the amount of data 
that the UE has available for transmission. The Cell Update 
message only contains a cause value indicating the cause for 
5 the cell update, in this case "uplink data transmission" . 

This means that the UTRAN has to move the UE to CELL_DCH 
without knowing if this is necessary or even desired. For 
small data objects the transmission time on CELL_FACH is 
smaller than on CELL.DCH due to the relatively large delay 
10 to setup the DCH channel. Thus it would in fact reduce the 
user performance if the UE is moved to CELL_DCH when the 
available amount of data is small. Given that it consumes 
network resources to move users to DCH, these resources are 
wasted if the UE is moved to DCH when there is no need. 

15 It is known that the Cell Update message can be extended 
with a traffic volume measurement. However, due to 
limitations on the air interface and the fact that the Cell 
update is transmitted on RLC transparent mode it is not 
desirable to extend the message size to the extent that 

20 would be needed. 

A solution to the problem described above is to modify the 
Cell Update message in a way that provides certain 
information about the traffic volume without significantly 
increasing the message size. The general idea is that 

25 instead of indicating the Traffic Volume explicitly, it is 
indicated in relation to a threshold, e.g. if the Traffic 
Volume is above a previously configured threshold. This 
threshold can be configurable by UTRAN. Normally the traffic 
volume measurements in the UE are configured in such a way 

30 that measurement reports in CELL_FACH are transmitted if the 
traffic volume exceeds a threshold and potentially the same 
value as used to trigger the transmission of a measurement 
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report could be used for setting the flag in the Cell update 
message. This method would mean that no downlink signalling 
would need to be changed. However, the threshold for the 
Cell Update message can also be configured separately. 

5 In addition to the Traffic Volume information it could be 
beneficial to indicate further information, e.g. if the 
uplink data is available on a user radio bearer or a 
signalling radio bearer. This could potentially also be 
indicated in the cell update message. The benefit with this 
10 additional info would be that the UTRAN may choose not to 
move UEs to CELLJDCH if the data comes from a signalling 
radio bearer since the transmission on signalling radio 
bearers is not expected to be extended in time. 

In order to reduce the DCH setup time from CELL_PCH and 

15 URA_PCH it is an object of the present invention to be able 
to perform a direct switch to CELLJDCH. To facilitate a 
direct switch the present invention proposes to modify the 
format of the CELL_UPDATE message to indicate, e.g., whether 
the UE has a traffic volume above a configured threshold, 

2 0 which is preferably the same as the threshold for triggering 
of the traffic volume measurement. As it would imply a 
significant increase of the size of an enhanced CELLJJPDATE 
message with the information about the available UL traffic 
volume such that it would no longer fit into one RLC PDU, an 

2 5 alternative is to indicate with a flag if the traffic volume 
is, e.g., above the traffic volume threshold configured for 
the traffic volume measurement. This information is 
considered sufficient to assist the UTRAN in the decision if 
a UE should be moved to CELL_DCH or not and could facilitate 

30 the direct transfer to CELLJDCH from CELL/URAJPCH. 

The following describes by means of non-limiting examples 
two conceivable embodiments to indicate said information. 



7 



in a first embodiment the Cell Update message is extended 
with a flag, e.g. a single bit, indicating the relation to a 
threshold value, e.g. if the traffic volume in the UE xs 
above a threshold. Potentially a second bit is used to be 
5 able to separate if the traffic volume is available on an 
SRB or an RB {or both) . This would extend the message size 
with a few bits including those needed for coding of the 
message extension. 

Another embodiment of the present invention uses currently 
10 reserved Code points. In the current cell update message 
there exist some spare values, i.e. code points that are 
currently not used but could be transmitted with the 
existing message coding. Thus, it would be a possible 
embodiment of the present invention to use one of the 
15 reserved code points in the Cell Update message to indicate 
the Traffic Volume, e.g. if the Traffic Volume is above the 
threshold. Potentially, up to several code points are used 
to he able to separate if the traffic volume is available on 
an SRB or an RB (or both) . For example, a code point I could 
20 indicate a Traffic Volume above the threshold on an RB, a 
code point II could indicate a Traffic Volume above the 
threshold on an SRB, and a code point III could indicate a 
Traffic Volume above the threshold on both SRB and RB. This 
method would not increase the message size at all. 

25 The method according to the present invention makes it 
possible to move user equipments quickly to CELL_DCH in case 
the traffic volume is large and to move user equipments to 
CELL_FACH in case the traffic volume is small. The method 
facilitates direct transition to DCH which reduces the DCH 

30 setup time significantly. The method can thus greatly 
improve the performance for applications where the UE is 
typically in CELL_URA_PCH when data needs to be transmitted, 
e.g. web surf ing . 
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Turning back to figure 4, the alternative signaling sequence 
for UTRAN initiated transmission described in said figure 
could be seen as somewhat faster than the sequence in figure 
2. However, since UTRAN have all the knowledge about the 
5 downlink buffers for this UE and know already when sending 
the Paging type 1 message that the UE should be moved to 
CELiIj_DCH state, there is no need to have the UE go via the 
CELL_FACH state before continuing the transition to CELL_DCH 
state. Performing Cell update procedure in CELL_FACH state 
10 (step 2 and 3 in figure 4) takes a substantial amount of 
time since the messages are sent on contention based common 
channels used by several users. By removing these steps in 
CELL_FACH state the sequence could therefore be made even 
faster if the UE transits directly from CELL_PCH/URA_PCH to 
CELLi_DCH . This faster sequence is currently not supported in 
the 3 GPP specifications. 
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When a UTRAN initiated transition from CELL_PCH/URA_PCH to 
CELL_DCH is performed the UE shall transit directly to 
CELL_DCH without exchanging messages in CELL_FACH state in 
between. The CELL_PCH/URA_PCH transition to CELL_DCH would 
be made faster if the paging message would contain the DCH 
configuration. This would result in a signaling sequence as 
shown in figure 5. In this alternative, the UTRAN orders the 
UE to CELL_DCH already in the Paging type 1 message in step 
25 1. The UE responds with a Radio Bearer Reconfiguration 
Complete message in step 2 and can then start to receive 
data on DCH. In order to make this solution possible a 
number of information elements need to be added to the 
paging type 1 message. In fact the same content that is 
present in cell update confirm in figure 4 should be added 
to the paging message. Also compared to the content of cell 
update confirm the identity used in the paging type 1 
message is U-RNTI and not C-RNTI. 
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Additional message content to the paging type 1 message 
would be: 

Frequency, UL DPCH info (e.g. scrambling code, spreading 
factor, TFCI configuration), DL DPCH info (e.g. spreading 
5 factor, rate matching, power offsets) DL RL info (e.g. 
primary CPICH) , power control configurations and potential 
HS-DSCH configurations. 

Some other information related to RB and Transport channels 
could also be beneficial, but since the paging type 1 
10 message is sent in TM mode and without segmentation or re- 
transmissions the size need to be limited, only the crucial 
information have been listed here. 

It could be noted that normally the cell where the UE is 
located is not known when the UE is in URA_PCH state, so the 
invention is of limited use for this scenario. This is 
because UTRAN need to know already when sending the paging 
message in which cell the UE is located in order not to 
establish a dedicated channel for the UE in all cells 
belonging to the URA. This could of course be done but would 
potentially mean waste of radio resources. 

Therefore the invention is in particular beneficial for 
CELL_PCH UEs. For URA_PCH Ues there is a benefit in case 
the UE has made its presence in a cell known to UTRAN rather 
recently . 

25 There are two possibilities to indicate the information: 

Explicit indication: The Paging type 1 message is extended 
with the explicit information needed to perform the direct 
transition to CELL_DCH. 
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implicit indication: In order to save space in the paging 
type 1 message previous messages (e.g. a RB reconf iguratxon 
message) moving the UE to CELL_PCH/URA_PCH could include 
most of the configurations needed to perform the direct 
transition to CELL_DCH at a later stage. The paging type 1 
message itself that could be sent a long time later, then 
only includes the actual code that the UE should use and/ or 
a pointer to the already sent physical channel 
configuration. As an alternative to extending the paging 
message with DCH information, the Cell Update Confirm 
message could be modified to be transmitted on the paging 
channel (step 1 in figure 5). The method makes it possible 
to move UES quickly to CEL>Ii_DCH in case the traffic volume 
is large. The method facilitates direct transition to DCH 
which reduces the DCH setup time significantly. The method 
can greatly improve the performance for applications where 
the UE is typically in CELL_PCH/URA_PCH when data needs to 
be transmitted to the UE (e.g. Push-to-Talk services) . 
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